The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In a business-to-business environment, applications executing on computers commonly communicate with other applications that execute on other computers. For example, an application “A” executing on a computer “X” might send, to an application “B” executing on a computer “Y,” a message that indicates the substance of a purchase order.
Computer “X” might be remote from computer “Y.” In order for computer “X” to send the message to computer “Y,” computer “X” might send the message through a computer network such as a local area network (LAN), a wide-area network (WAN), or an inter-network such as the Internet. In order to transmit the message through such a network, computer “X” might use a suite of communication protocols. For example, computer “X” might use a network layer protocol such as Internet Protocol (IP) in conjunction with a transport layer protocol such as Transport Control Protocol (TCP) to transmit the message.
Assuming that the message is transmitted using TCP, the message is encapsulated into one or more data packets; separate portions of the same message may be sent in separate packets. Continuing the above example, computer “X” sends the data packets through the network toward computer “Y.” One or more network elements intermediate to computer “X” and computer “Y” may receive the packets, determine a next “hop” for the packets, and send the packets towards computer “Y.”
For example, a router “U” might receive the packets from computer “X” and determine, based on the packets being destined for computer “Y,” that the packets should be forwarded to another router “V” (the next “hop” on the route). Router “V” might receive the packets from router “U” and send the packets on to computer “Y.” At computer “Y.” the contents of the packets may be extracted and reassembled to form the original message, which may be provided to application “B.” Applications “A” and “B” may remain oblivious to the fact that the packets were routed through routers “U” and “V.” Indeed, separate packets may take different routes through the network.
A message may be transmitted using any of several application layer protocols in conjunction with the network layer and transport layer protocols discussed above. For example, application “A” may specify that computer “X” is to send a message using Hypertext Transfer Protocol (HTTP). Accordingly, computer “X” may add HTTP-specific headers to the front of the message before encapsulating the message into TCP packets as described above. If application “B” is configured to receive messages according to HTTP, then computer “Y” may use the HTTP-specific headers to handle the message.
In addition to all of the above, a message may be structured according to any of several message formats. A message format generally indicates the structure of a message. For example, if a purchase order comprises an address and a delivery date, the address and delivery date may be distinguished from each other within the message using message format-specific mechanisms. For example, application “A” may indicate the structure of a purchase order using Extensible Markup Language (XML). Using XML as the message format, the address might be enclosed within “<address>” and “</address>” tags, and the delivery date might be enclosed within “<delivery-date>” and “</delivery-date>” tags. If application “B” is configured to interpret messages in XML, then application “B” may use the tags in order to determine which part of the message contains the address and which part of the message contains the delivery date.
Sometimes, malicious users attempt to disrupt the communications described above by mounting a “denial-of-service” attack on a server application—application “B” in the example above. Traditionally, denial-of-service attacks are conducted by continuously sending very large quantities of data packets toward a server application. The server application receives these data packets and attempts to process the messages contained therein, consuming a portion of the processing resources of the computer that hosts the server application in doing so. If the server application receives enough data packets from a malicious user, then all or nearly all of the server application's host's processing resources may become occupied with processing the bogus messages from the malicious user. Additionally or alternatively, a malicious user may deploy malicious software, or “malware,” which may cause an application to crash or become unavailable, or may cause an application to perform large amounts of computations, or may cause an application to fetch unauthorized content or modify content that the application should not modify.
As a result, the server application's ability to process legitimate messages sent from legitimate users decreases immensely. Indeed, the server application might not be able to process a legitimate message until after an unacceptable amount of time passes after the legitimate message was sent. Legitimate client applications—such as application “A” in the example above—may assume, due to the lack of a timely response from the server application, that the server application is no longer operational.
In an attempt to thwart such traditional denial-of-service attacks, an automated sentry process is sometimes established between the server application and all other applications that might send packets toward the server application. For example, the sentry process might execute on the same computer as the server application, or on some intermediate network appliance that acts as a proxy for the computer that hosts the server application. In any case, the sentry process receives data packets before sending the data packets on to the server application.
Under this sentry approach, legitimate client applications need to be configured to send packets toward the sentry process rather than the server application itself, because the server application is configured to receive packets only from the sentry process. The configuration process can be a burden to users and/or programmers of the legitimate client applications, especially where a different customized configuration is required for each different sentry process toward which a client application might send packets.
When a sentry process receives a data packet, it inspects the protocol headers—such as the IP and TCP headers—of the data packet and stores state information concerning one or more characteristics of the protocol headers. For example, for each packet that a sentry process receives, the sentry process might record the source IP address indicated in the packet's IP header. If the sentry process determines that a significantly high number of data packets have been received from the same source IP address within a relatively short period of time, then the sentry process may conclude that an application associated with the source IP address is conducting a denial-of-service attack. In response to such a determination, the sentry process may take some protective action, such as alerting a network administrator or the server application.
Though burdensome, the sentry approach described above may be somewhat effective in deterring traditional denial-of-service attacks. However, being rather persistent, malicious users have innovated non-traditional denial-of-service attacks that effectively circumvent the protections provided by the sentry approach. Using a “distributed” denial-of-service attack, multiple separate computers, each having a different IP address, may cooperate to send, concurrently, a large quantity of data packets toward a target. The number of data packets that each individual attacker sends is not large enough to trigger the sentry process' protective countermeasures, but the combined mass of all of the attackers' data packets is enough to deluge the target and consume most of the target's processing resources.
Other non-traditional attacks are even more sophisticated and more easily conducted. A server application might have a published interface to which messages from client applications need to conform in order for the server application to process those messages. The server application might not be robust enough to handle messages that do not conform to the interface. For example, a server application's interface might expose a method that accepts an integer as a parameter. If the server application receives a message that invokes the method with a floating-point number parameter instead of the expected integer parameter, the server application might behave erratically; the server application might corrupt legitimate data, or the server application might even become non-responsive to further messages from legitimate client applications. Because the non-conforming elements usually are contained in a data packet's payload portion instead of the data packet's protocol headers, the sentry approach described above is powerless to defend against such an attack.
Although it might initially seem feasible to defend against such non-traditional attacks by adjusting the sentry process so that the sentry process would inspect the payload portions of data packets to ensure that the payload portions do not contain any non-conforming elements, such a defense would merely transfer the point of vulnerability from the server application to the sentry process. Because payload inspection is processing resource-intensive, malicious users could send data packets to the sentry process at a greater rate than the sentry process could inspect the payload portions of those data packets. When the processing resources of the sentry process' host computer became entirely or almost entirely consumed with inspecting data packet payloads, the denial-of-service attack would have achieved its goals, since the sentry process would not be able to send legitimate data packets to the server application in a timely manner. Whenever the server application only receives data packets from a single sentry process, the sentry process becomes a vulnerable bottleneck.
For security reasons, the payload portions of some legitimate data packets may be encrypted before being sent toward a server application over encrypted sessions. Even if a sentry process were designed to inspect data packet payloads, the sentry process would not be able to detect offensive content contained in a data packet payload if that content was encrypted in such a way that only the server application could decrypt the content.
The form of denial-of-service attacks continuously changes. Almost as soon as a sentry process is developed to counter one form of attack, another form of attack, against which the sentry process cannot defend, emerges. By the time that sentry process developers have shipped the next revision of a sentry process to counter new forms of attack, significant damage from those new forms of attack might already have been done.
Thus, previous approaches for negating denial-of-service attacks in a network are only partially effective, inherently vulnerable, and limited in longevity. A more effective, adaptive, and invulnerable technique for preventing denial-of-service attacks in a network is needed.